Skip to content

docs(research): record compact u4 bit-table negative result - #85

Closed
brenorb wants to merge 1 commit into
solving-bitcoin:mainfrom
brenorb:feat/u4-compact-bits
Closed

brenorb wants to merge 1 commit into
solving-bitcoin:mainfrom
brenorb:feat/u4-compact-bits

Conversation

@brenorb

@brenorb brenorb commented Sep 11, 2026

Copy link
Copy Markdown
Contributor

Summary

  • record an experiment removing the zero sentinel from the 61-item u4 nibble-to-bits table
  • preserve the measured 61-item construction as the practical baseline
  • document the theoretical 234-to-235 item-budget gain and the execution-time failure

Evidence

  • exhaustive single-nibble and multi-nibble correctness probes passed
  • checked -1 and 16 inputs were rejected
  • baseline focused u4 bit tests pass
  • python3 tools/kb.py validate
  • git diff --check

The maximum compact schedule remained CPU-bound for several minutes in the pinned local interpreter and was terminated before completion; no strict deployment or stack-boundary claim is made. The full repository suite was not run.

Copy link
Copy Markdown
Contributor

Review recommendation: close or replace this version.

The negative result claims successful correctness experiments and optimizer timeouts without retaining the experiment implementation or sufficient reproduction commands/configuration. Close this version or supply the code, deterministic inputs, compiler policy, timing configuration and explicit failure criteria so the result is evidence-backed and reproducible.

September 11 local validation (unchanged PR head): python3 tools/kb.py validate passed.

Reviewed commit: d0eaf382201197b63def783707a6c9a443128f52.

@brenorb

brenorb commented Sep 18, 2026

Copy link
Copy Markdown
Contributor Author

Closing as requested by review. This negative result does not retain the experiment implementation, deterministic fixtures, exact compiler/optimizer policy, timing configuration, timeout criteria, or logs needed to reproduce the claims. The reported 235-nibble capacity is only the arithmetic bound (4×235 + 60 = 1000), not a measured peak including branch temporaries, and the claimed optimizer slowdown is not separated from interpreter execution. The proposed NR-043 identifier is also already occupied on current main. Reopen only with recovered evidence and a reproducible rerun.

@brenorb brenorb closed this Sep 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants